Computing systems today are increasingly exposed to security threats that may compromise data stored on the systems and functionality of the systems themselves. For instance, a computing device can be infected with malware that enables unauthorized access to data stored on the device, and/or that can enable functionality of the device to be hijacked by an unauthorized party.
Trusted Platform Modules (TPM) help improve security for computing systems. A TPM is a computer chip (microcontroller) that is typically part of a computer's motherboard. TPMs provide for hardware-based authentication and attestation. Authentication is a process for proving that a computing device is what it claims to be. Attestation is a process for proving that a computing device is trustworthy and has not been breached.
Generally, a TPM represents a secure processing environment that can be leveraged to store security assets, such as security keys, certificates, and passwords, that are used to authenticate a platform (e.g., computing devices, mobile devices, network equipment). Further, a TPM can be utilized to store measurements of valid device states (e.g., operating system states), which can be used to ascertain whether a current device state has been compromised such that the device may be unsecure and/or untrusted.
The trusted platform module (TPM) can be used to create cryptographic public/private key pairs in such a way that the private key can never be revealed or used outside the TPM. This type of key can be used to guarantee that a certain cryptographic operation occurred in the TPM of a particular computer by virtue of the fact that any operation that uses the private key of such a key pair must occur inside that specific TPM.
Encryption, Digital Signatures, and Certificates
Encryption typically works by using a private key/public key pair (referred to as “public key cryptography” or “PKI”). Data that is encrypted with one key can be decrypted only with the other key from the key pair. The keys in the key pair are similar. Generally, the keys are based on prime numbers and have a sufficient length (e.g., bits) to make it extremely difficult to decrypt data without the correct key. One key is kept secret (the private key) and the other key (the public key) is distributed. Anybody with the public key can encrypt data that then can be decrypted only by the holder of the corresponding private key.
Key pairs can also be used for digital signatures to certify that a message is coming from who it is supposed to be coming from. The owner of the keys signs the data with the private key. The receiver of the data can compare the signature against the public key, and if they match, have proof as to the identity of the sender of the message.
For public-key cryptography to be valuable, users must be assured that the other parties with whom they communicate are “safe”—that is, their identities and keys are valid and trustworthy. To provide this assurance, users must have a registered identity. These identities are stored in a digital format known as a certificate. Certification Authorities (CAs) represent the people, processes, and tools to create these digital certificates that securely bind the names of users to their public keys. In creating certificates, CAs act as agents of trust. As long as users trust a CA and its business policies for issuing and managing certificates, they can trust certificates issued by the CA. CAs create certificates for users by digitally signing a set of data that includes the following information, among other things:                the user's name in a distinguished name format;        a public key of the user;        the validity period (or lifetime) of the certificate (a start date and an end date); and        the specific operations for which the public key is to be used (whether for encrypting data, verifying digital signatures, or both).        
The CA's signature on a certificate allows any tampering with the contents of the certificate to be easily detected. As long as the CA's signature on a certificate can be verified, the certificate has integrity. Since the integrity of a certificate can be determined by verifying the CA's signature, certificates are inherently secure and can be distributed in a completely public manner (for example, through publicly-accessible directory systems).
Users retrieving a public key from a certificate can be assured that the public key is valid. That is, users can trust that the certificate and its associated public key belong to the entity specified by the distinguished name. Users also trust that the public key is still within its defined validity period. In addition, users are assured that the public key may be used safely in the manner for which it was certified by the CA.
TPM Keys
Generally, a TPM has two types of keys: an endorsement key (“EK”) and an attestation identity key (“AIK”).
The Endorsement Key (EK) is a restricted encryption key (comprising a private/public key pair) that is permanently embedded in the TPM security hardware, generally at the time of manufacture. The EK is the root of the TPM's identity. The private portion of the EK (EKPriv) is never visible outside of the TPM. Because the EK can only be used for encryption, possession of the private EK (EKPriv) can only be proved indirectly, by using it to decrypt a value that has been encrypted with the public EK (EKPub). Therefore, while the EK cannot be used to produce a digital signature, it is able to provide for TPM authentication based on decryption operations. In sum, the private portion of the endorsement key (EKPriv) is never released outside of the TPM. The public portion of the endorsement key (EKPub) helps to recognize a genuine TPM.
The Attestation Identity Key (“AIK”) is a restricted signing RSA key (comprising a private/public key pair) that is used to provide platform authentication based on the attestation capability of the TPM. AIKs allow the TPM to produce cryptographically signed attestation evidence (statements) about the operational state of the platform. These signed statements can augment the current Trusted Network Connect (TNC) protocols, making them more resilient to local attacks by malware and to attempts by endpoints to misrepresent their operational state.
Key Attestation
Key attestation or TPM attestation refers to cryptographically proving a key comes from (e.g. is resident in) the TPM of a particular platform or device. A user certificate with a TPM-attested key provides higher security assurance backed up by non-exportability, anti-hammering, and isolation of keys provided by the TPM. For example, with TPM key attestation, an administrator can define the set of devices that users can use to access their corporate resources and have strong guarantees that no other devices can be used to access them. This access control paradigm is strong because it is tied to a hardware-bound user identity.
An EK certificate (which is also resident in a TPM) is used to bind an identity, in terms of specific security attributes, to a TPM.
Real-world uses of the AIK, like health attestation or key attestation, require AIK trust from the entity to whom the device health or key data is being attested. This trust is embodied in an AIK certificate, which is issued from public servers of an AIK Issuance Service. This certificate is proof that the AIK is a Restricted Signing TPM key, and may not be used to sign TPM information (Health attestation or key attestation claims) that are not true. An AIK certificate is used to attest to the presence of an AIK within a TPM. It is also used to attest that other keys certified by the AIK did in fact originate from that particular TPM.
However, current implementations of AIK certificate issuance require two or more network hops or round trips from the client device to the public AIK issuance servers. Current implementations of health certificate issuance require two or more round trips to the AIK issuance servers plus an additional hop or round trip to a health issuance server. Further, some private networks do not grant access to the public AIK certificate issuance servers, so provisioning an AIK certificate (and thus a health certificate) may be impossible on devices restricted to these networks.
It is with respect to these and other general considerations that aspects of the technology have been made. Also, although relatively specific problems have been discussed, it should be understood that the aspects of the technology presented should not be limited to solving the specific problems identified in the background.